Classical peer-to-peer (P2P) solutions, that is, solutions where the entities—programs—communicate with each other directly, typically run on personal computers, sharing the resources of the latter. P2P solutions on mobile devices, such as Bittorrent, for example, can only function effectively having a background with powerful personal computers (PCs) or with a cloud-based background, for several reasons.
One reason of the limitations is Network Address Translation, NAT, under which the specific internal network devices are assigned an internal IP address instead of a real, public IP address, and this internal IP address is translated by an address translation device so that, externally, in an external network, a public IP address assigned to the individual packets is visible. This method is particularly widespread at service providers offering or providing wireless communication. Namely, with the depletion of the total number of 2564 of the IP4 addresses, network providers make increasing use of NAT or service provider's NAT, Carrier Grade Network Address Translation, CGNAT, solutions, i.e. address translations where every user is put behind NAT and, therefore, establishing a connection is a problem at the user, depending on the specific type of NAT. This problem is basically known in telephony, but it occurs with increasing frequency also in relation to the Internet. In P2P networks and in some applications using the P2P paradigm such as e.g. VoIP, IM, where not only service providers, but normal end-user terminals would also like to communicate with each other, communication between the parts realised with NAT functionalities in the networks is a major problem. Consequently, it is a typical fundamental problem that two users cannot establish direct contact with each other, because the service provider of one user rejects the connection-establishing requests coming from the other user, as outlined in FIG. 1.
In certain cases—symmetric NAT—devices behind NAT cannot be addressed from outside, from the side of the Internet so in such cases only the user behind the NAT can initiate an Internet connection. In the particular case when two devices behind their respective symmetric NATs, e.g. mobile phones, would like to communicate with each other, they will not be able to do so.
Nowadays two methods are known to handle such cases. Either the device (mobile phone, or set-top-box) instructs the running NAT service to open the necessary ports (see e.g. the UPNP protocol, a standard protocol to configure home NAT) or, in a generic solution to the problem, a mediator is involved between the two parties that cannot contact each other: it is permitted to establish connection with the intermediate entity and hence the intermediary entity and the user can communicate. The intermediary entity relays the traffic between the two communicating entities, as is also outlined in FIG. 1.
Communication takes place on two planes:                Signalling—data of minor quantity, present on a mandatory basis or presumably, e.g. push or P2P overlay.        Data traffic—data of major quantity that the parties are reluctant to transfer, but a third party involvement implies a security risk.        
The experience is that users are reluctant to consent to their devices being the transmitters of data of larger quantities and, with mobile devices, neither is the transmission of large amounts of data to each other (e.g. vice/video calls) a technologically adequate solution due to energy and other problems. Signalling (call, ring etc.), however, is feasible also at this level.
The problem, therefore, is the adequate transmission of the data transmitted on the data channel (but that may also be the signaling itself). This communication problem is generally handed by one of two approaches:                Solutions developed for this purpose include the standard protocols TURN (http://tools.ietf.org/html/rfc5766) and ICE (http://tools.ietf.org/html/rfc5245) and their specific implementations. TURN mediates between two communicating entities as a third party, with the traffic going through it; the dynamic domain name server, DNS, only connects the dynamic IP address to a constant URL. The TURN protocol itself, as is, is not suitable for the user concerned to connect two other users. It can only manage connections between the given user and related entities.        A P2P network itself can also provide for nodes that realise the transfer (so-called super-nodes).        
Big central TURN service providers, however, are not economical, since they ought to transmit high-volume traffic, and neither are they necessarily advantageous in terms of data security.